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Big  'A'  Systems  Architecture 

From  Strategy  to  Design:  Systems  Architecting  in  DoD 


Chris  Robinson 


5  a  Systems  Engineering  in¬ 
structor  at  DAU,  I  have  en¬ 
gaged  in  a  number  of  discus¬ 
sions  and  debates,  both  in 
and  out  of  the  classroom, 
on  architecture  in  systems 
acquisition.  Over  time,  I 
began  to  see  there  was 
a  real  lack  of  consensus 
about  the  importance 
of  architecture,  how  it 
fits  in  to  the  Defense 
Acquisition  System  (DAS),  and  how 
it  relates  to  system  engineering. 

I,  admittedly,  had  a  somewhat  narrow  view  of  the  subject  when  I  first  got 
into  the  acquisition  business.  I  viewed  architecture  as  simply  an  output  of  the 
design  process.  I  understood  architecture  to  be,  simply,  the  block  diagram 
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that  depicted  all  the  major  components  of  a  system  and  il¬ 
lustrated  how  those  components  are  logically  or  physically 
connected  together.  Certainly  that  block  diagram  was  part  of 
it,  but  as  I  worked  in  various  engineering  and  management 
roles  at  different  stages  of  the  development  life  cycle,  I  started 
to  see  a  bigger  picture.  I  began  to  understand  the  importance 
of  architecture  as  a  discipline  that  goes  well  beyond  that  block 
diagram. 

DAU  has  afforded  me  the  opportunityto  learn  more  about  the 
various  perspectives  on  architecture  and  system  architecting 
from  colleagues,  students,  and  the  broader  acquisition  com¬ 
munity.  I  also  have  had  the  opportunity  to  study  the  subject 
in  more  depth. 

My  observation  is  that  systems  architecting  in  DoD  is  best 
understood  from  the  perspective  of  the  broader  Big  "A"  ac¬ 
quisition  enterprise  that  includes  not  only  system  developers, 
but  strategy  and  policy  makers,  resource  sponsors,  and  com¬ 
bat  developers.  I  refer  to  this  framework  as  Big  "A"  systems 
architecting. 

Systems  Architecting  As  Design 

Fundamentally,  system  architecting  is  part  of  the  system 
engineering  design  process  where  decisions  are  made  that 
significantly  affect  stakeholder  needs  and  life-cycle  costs. 
A  system's  architecture  defines  the  components  of  the 
system,  the  interfaces  among  those  components,  and  the 
processes  or  rules  that  govern  how  the  components  and 


interfaces  change  over  time.  This  definition,  however,  does 
not  tell  the  whole  story,  nor  does  it  capture  the  vital  role 
that  effective  system  architecting  has  in  achieving  success¬ 
ful  acquisition  outcomes.  During  system  development,  the 
emerging  structure  of  a  system  sets  the  baseline  for  the  work 
to  follow.  Early  life-cycle  decisions  that  affect  this  emerging 
structure  will  have  a  large  impact  on  the  evolution  of  the 
system's  design,  verification,  production,  sustainment,  and 
disposal,  and,  therefore,  a  significant  impact  on  the  system's 
life-cycle  costs.  Consequently,  architectural  decisions  pro¬ 
vide  the  basis  for  the  detailed  technical  planning  needed  to 
effectively  manage  these  life-cycle  activities.  The  evolution 
of  the  technical  plan  will  parallel  the  evolution  of  the  behavior 
and  structure  of  the  system. 

Architecting  is  the  part  of  the  system  engineering  design 
process  that  involves  decisions  related  to  the  behavior  and 
structure  of  a  system  that  are  significant  in  achieving  an  opti¬ 
mal  balance  among  stakeholder  objectives  and  total  system 
cost.  Systems  architecting  develops  a  deep  understanding  of 
the  required  system  behavior  that  is  traceable  to  an  overall 
goal  and  achievable  within  established  constraints.  This  un¬ 
derstanding  informs  the  thoughtful  partitioning  of  the  whole 
into  constituent  components,  the  definition  of  the  relationships 
among  these  components,  and  the  processes  that  govern  how 
the  structure  and  relationships  among  system  components 
change  over  time.  Architects  set  the  boundaries  of  the  system, 
define  the  system's  relationship  with  the  larger  context  (i.e., 
system  of  systems  or  business  enterprise),  and  provide  focus 


Figure  1.  Sysfems  Architecting  and  the  Sysfems  En0neering  Technical  Processes 

Architectural  Descriptions  Systems  Engineering  Technical  Processes 


baseline  in  models  that  describe  the  system  from  various  perspectives  at  successive  levels  of  development 
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for  detailed  component-level  engineering.  This  partitioningfa- 
cilitates  collaboration  by  helping  stakeholders  visualize  emerg¬ 
ing  solutions  from  their  unique  perspectives,  helps  systems 
developers  get  a  handle  on  complexity,  and  supports  analytical 
activities  used  to  evaluate  and  assess  system  performance. 

Figure  1  illustrates  the  relationship  of  the  systems  engineer¬ 
ing  design  process  to  architectural  descriptions  that  are  both 
artifacts  of  and  inputs  to  the  process.  Architectural  descrip¬ 
tions  capture  the  results  of  each  step  in  the  process,  but  also 
set  the  stage  for  subsequent  steps.  Composing  architectural 
descriptions  is  a  discovery  and  learning  process  that  helps 
drive  the  iterative  refinement  of  a  system's  high-level  design 
as  steps  in  the  systems  engineering  process  are  repeated  to 
converge  to  a  solution. 

Systems  Architecting  As  Art  With  Engineering 

The  transformation  from  strategic  objectives  to  the  structure 
of  a  system  solution  often  is  characterized  by  great  complexity. 
This  complexity  is  driven  by  myriad  competing  stakeholder 
concerns  as  well  as  technological  and  environmental  chal¬ 
lenges.  Thus,  the  architecting  process  depends  as  much  on 
the  "artistic  talents"  of  the  architects  involved  as  it  does  on 
their  engineering  acumen.  The  architecting  process  makes 
extensive  use  of  heuristics  ("rules  of  thumb"  based  on  lessons 
learned  from  experimentation  and  experience)  and  judgment 
in  order  to  deal  with  complexity,  and  places  less  emphasis  on 
engineering  analysis  to  decide  on  the  best  approach  (see  The 
Art  of  Systems  Architecting  by  Mark  W.  Maier  and  Eberhardt 
Rechtin  for  a  more  in-depth 
discussion  on  the  use  of  heu¬ 
ristics  in  architecting  systems). 

Understanding  and  defining 
the  problem  to  be  solved,  ap¬ 
plying  experience  and  lessons 
learned,  balancing  the  needs 
of  all  stakeholders,  evaluating 
alternative  approaches,  and 
choosing  the  best  way  forward 
constitute  a  highly  creative, 
artistic  process.  The  creative 
aspects  of  systems  architect¬ 
ing  require  architects  to  be  ef¬ 
fective  communicators  and  to 
possess  a  sound  understand¬ 
ing  of  the  technical  landscape 
(i.e.,  knowledge  of  technical 
standards  and  certification  re¬ 
quirements,  knowledge  of  the 
relevant  engineering  domains, 
and  knowledge  of  enterprise- 
level  rules  and  processes).  This 
thoughtful  aspect  of  systems 
architecting,  with  its  applica¬ 
tion  of  heuristics  and  "soft" 
engineering,  is  necessarily 
complemented  by  the  rigorous 


"hard"  engineering  analysis  required  to  evaluate  architectural 
decisions  and  assess  the  performance  of  alternatives. 

Systems  Architecting  As  Modeling 

In  addition  to  its  artistic  nature,  the  architecting  process  is 
characterized  by  its  use  of  modeling.  Models  serve  as  the 
canvas  on  which  the  systems  architecting  process  is  realized. 
Modeling  helps  architects  think  about,  understand,  and  pres¬ 
ent  the  system  of  interest.  Each  step  in  the  systems  architect¬ 
ing  process  is  captured  in  a  set  of  models  that  organize  under¬ 
lying  architectural  data  so  as  to  clearly  describe  a  solution  from 
various  perspectives.  Architects,  engineers,  and  managers 
use  these  architectural  descriptions  to  plan  for  and  manage 
subsequent  development  efforts  and  to  communicate  techni¬ 
cal  information  to  stakeholders.  Models  can  be  documents, 
spreadsheets,  dashboards,  block  diagrams,  or  other  graphical 
representations  that  serve  as  a  template  for  organizing  and 
displaying  complex  information  in  a  more  comprehensible 
format. 

When  data  are  collected  and  presented  as  a  "filled-in"  model, 
the  result  is  called  a  view.  The  Department  of  Defense  Ar¬ 
chitecture  Framework  (DoDAF)  provides  a  standard  set  of 
building  blocks  and  conventions  for  capturing  architectural 
data  and  presenting  those  data  in  various  formats  that  target 
specific  perspectives  or  concerns.  The  DoDAF  defines  a  set  of 
templates  (DoDAF-defined  models)  that,  when  filled  in  with 
solution-specific  architectural  data,  provide  a  completed  ar¬ 
chitectural  view.  Logically  organized  collections  of  views  are 


Figure  2.  Systems,  Architectures,  and  Architectural 

Descriptions  (adapted  with  permission  from  lecture  notes  of  Matthew  Henry, 
Johns  Hopkins  University) 
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referred  to  as  viewpoints.  A  set  of  viewpoints  related  to  a  spe¬ 
cific  system  solution  is  collectively  called  the  architectural  de¬ 
scription  of  that  system. 

Figure  2  describes  the  relationship  among  a  system,  its  ar¬ 
chitecture,  and  the  description  of  the  architecture.  A  system 
can  support  one  or  more  missions,  but  each  system  is  un¬ 
derstood  to  have  just  one  architecture.  This  architecture  can 
have  multiple  architectural  descriptions,  and  those  archi¬ 
tectural  descriptions  typically  conform  to  an  architectural 
framework.  An  architectural  framework  defines  a  set  of 
models  (standard  templates),  views  (filled-in  models),  and 
viewpoints  (logical  groupings  of  views)  that  can  be  used 


document  what  has  already  been  decided.  The  production  of 
architectural  descriptions  frequently  is  treated  as  a  "check  in 
the  block"  required  to  get  past  the  next  major  program  deci¬ 
sion  review. 

Instead,  program  offices  and  the  broader  acquisition  com¬ 
munity  must  look  at  architecture  (or  systems  architecting) 
as  a  proactive  endeavor.  This  proactive  endeavor  leverages 
modeling  as  a  learning  and  discovery  process  vital  to  systems 
acquisition,  enabling  the  sound  decision  making  required  to 
successfully  transform  strategic  objectives  into  system  so¬ 
lutions.  I  believe  the  right  approach  for  the  acquisition  com¬ 
munity  is  to  focus  on  architecture  and  architecting  as  a  dis- 
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to  capture  and  present  architectural  data  in  standardized 
or  custom  formats.  Architectural  frameworks  like  DoDAF 
typically  define  a  set  of  fundamental  building  blocks— an 
architecting  "vocabulary"— that  provides  the  basis  for 
composing  architectural  views.  The  building  blocks  are  the 
primitive  elements  and  rules  used  to  create  architectural 
views  in  much  the  same  way  the  Periodic  Table  of  Elements 
is  used  to  describe  the  structure  of  chemical  compounds 
and  chemical  processes.  The  DoDAF  Meta-Model  (DM2)  is 
the  "vocabulary"'  of  DoDAF.  A  meticulously  defined,  com¬ 
prehensive  set  of  basic  modeling  elements  like  the  DM2 
is  necessary  to  ensure  that  architectural  descriptions  are 
standardized  down  to  the  data  element  level,  and,  as  a  re¬ 
sult,  portable  between  modeling  tools  and  easily  commu¬ 
nicated  and  understood  across  organizational  boundaries. 
This  aspect  of  architecting  is  especially  important  with  re¬ 
gard  to  interoperability  requirements  and  interoperability 
design  for  systems  that  exchange  information  with  other 
systems  within  an  enterprise  like  DoD.  This  is  why,  as  a  mat¬ 
ter  of  policy,  the  mandatory  Net  Ready  Key  Performance 
Parameter  (NR-KPP)— a  mandatory  KPP  that  helps  DoD 
ensure  systems  are  interoperable— is  elaborated  for  each 
system  through  the  development  of  DoDAF-compliant  ar¬ 
chitectural  descriptions. 

In  my  experience,  too  often  the  acquisition  community  fails 
to  integrate  architecting  activities  into  its  plans  efffectively. 
Architecture  is  viewed  as  a  retrospective  chore  used  only  to 


cipline  essential  to  the  system  engineering  and  management 
processes,  and  also  to  recognize  that,  in  DoD,  the  application 
of  this  discipline  actually  goes  beyond  the  boundaries  of  the 
acquisition  program  management  office  (PMO)  and  DAS,  and 
is  a  process  that  includes  the  broader  acquisition  enterprise. 

Big  ”A”  System  Architecting  in  DoD 

The  DAS  is  responsible  for  managing  development,  produc¬ 
tion,  and  sustainment  of  systems  and  for  doing  the  technical 
planning  that  supports  these  activities.  Accordingly,  it  might 
make  sense  that  the  DAS  (or  acquisition  program  manager) 
also  controls  the  systems  architecting  process,  and  that  this 
process  proceeds  in  a  linear  fashion,  starting  with  a  set  of 
stakeholder  requirements  and  ending  with  an  architectural 
description  of  a  solution  that  provides  the  basis  for  the  de¬ 
tailed  design  work  to  follow.  However,  I  believe  this  is  too 
narrow  a  perspective. 

Certainly,  the  DAS  plays  a  leading  role  in  the  architecting  of 
defense  systems,  but  I  believe  a  broader  perspective  is  needed. 
My  observation  is  that  the  systems  architecting  process  in 
DoD  transcends  the  DAS  and  involves  the  other  major  DoD 
decision  supports  systems— the  Joint  Capabilities  Integra¬ 
tion  Development  System  (JCIDS);  the  Planning,  Program¬ 
ming,  Budgeting,  and  Execution  System  (PPBES);  as  well  other 
strategic  operational-level  planning  and  decision  activities. 
This  holistic  enterprise  view  of  the  architecting  process  for 
complex  weapon  and  information  systems  sees  a  process  that 


Defense  AT&L:  March-April  2013 


26 


Figure  3.  Big  “A”  Systems  Architecting  in  DoD 
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cuts  across  organizational  boundaries  and  is  characterized  by 
a  high  degree  of  concurrency  among  its  constituent  stages 
(see  Figure  3). 

Accordingly,  systems  architecting,  in  light  of  this  broader  per¬ 
spective,  involves  Resource  Sponsors  and  Strategic  Planners 
(responsible  for  setting  the  strategic  context  and  allocating 
resources),  Combat  Developers  (responsible  for  operational 
or  mission  viewpoint),  as  well  as  System  Developers  (respon¬ 
sible  for  developing  the  materiel  or  technically  focused  system 
viewpoint).  As  shown  in  Figure  3, 1  refer  to  this  process  as  Big 
"A"  systems  architecting  to  reflect  the  cross-organizational  in¬ 
volvement  and  its  enterprise-wide  characteristic.  By  this  con¬ 
vention,  the  piece  of  the  process  that  falls  under  the  purview  of 
the  DAS  and  focuses  on  the  technical/technological  aspects  of 
systems  architecting,  rather  than  the  strategic  and  operational, 
can  be  thought  of  as  Little  "a"  systems  architecting. 


Figure  3  is  in  relation  to  the  early  acquisition  life-cycle  phases 
and  depicts  the  concurrency  that  exists  among  the  stages. 
What  this  concurrency  suggests  is  that  lower-level  architec¬ 
tural  definition— the  more  technically  focused  stages  man¬ 
aged  by  the  DAS— in  reality  begins  to  emerge  even  before  the 
outcome  of  higher-level  architectural  artifacts  are  fully  estab¬ 
lished  and  base  lined.  The  nature  and  degree  of  concurrency 
will  vary  from  program  to  program,  but  I  strongly  believe  the 
effectiveness  of  cross-organizational  collaboration  during  this 
highly  concurrent  Big  "A"  architecting  process  substantially 
influences  acquisition  outcomes. 

In  short,  the  idea  of  Big  "A"  Systems  Architecting  in  DoD  sug¬ 
gests  that  the  decisions  on  how  to  partition  a  system,  connect 
those  parts,  and  define  the  processes  and  rules  that  govern  its 
evolution  are  the  results  of  a  highly  concurrent  process  that  in¬ 
cludes  the  range  of  activities  from  modeling  and  documenting 
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department-level  strategic  goals  to  the  development  of  models 
that  describe  system  solutions  from  an  operational,  functional, 
physical,  and  technical  perspective.  These  models,  as  they  are 
developed,  provide  the  foundation  for  communication  among 
stakeholders,  drive  analyses  that  support  key  decision  mak¬ 
ing,  and  provide  the  basis  for  the  detailed  technical  planning 
required  to  efficiently  and  affordably  execute  an  acquisition 
program. 

The  significance  of  the  Big  "A"  systems  architecting  perspec¬ 
tive  is  that  it  reveals  opportunities  to  improve  the  overall 
acquisition  process.  I  believe  the  biggest  opportunities  rest 
with  the  institutionalization  of  emerging  modeling  method¬ 
ologies  such  as  Model  Based  Systems  Engineering  (MBSE) 
and  modeling  standards  such  as  Systems  Modeling  Language 
(SysML).  These  tools  have  great  potential  to  facilitate  col¬ 
laboration  and  improve  the  productivity  and  efficiency  across 
the  Big  "A"  systems  architecting  stages  in  the  early  acquisi¬ 
tion  life-cycle  phases.  Ideas  on  the  application  of  MBSE  and 
SysML  to  Big  "A"  systems  architecting  and  the  potential  ben¬ 
efits  to  acquisition  outcomes  are  planned  to  be  the  subject 
of  a  future  article. 

Summary  and  Conclusion 

Systems  architecting  is  part  of  the  systems  engineering  de¬ 
sign  process  that  results  in  the  partitioning  of  a  system  into 
components,  the  defining  of  interfaces  among  those  compo¬ 
nents,  and  the  processes  that  govern  their  change  over  time. 
This  is  a  critical  step  in  the  acquisition  of  a  system  since  it 


sets  a  framework  and  provides  a  roadmap  for  all  the  work 
that  follows.  More  important  is  that  systems  architecting 
supports  the  holistic  perspective  of  systems  engineering  and 
combines  the  art  of  balancing  stakeholder  concerns  with  the 
rigorous  use  of  engineering  analysis  to  handle  complex  prob¬ 
lems  that  require  a  system  solution.  The  systems  architecting 
process  is  captured  in  models— architectural  descriptions— 
that  describe  the  system  from  various  perspectives  related 
to  stakeholder  concerns.  Systems  architecting  is  a  learning 
process  that  leverages  models  and  modeling  to  understand 
and  define  problems,  communicate  alternative  solutions, 
support  analysis,  and  ultimately  capture  the  high-level  de¬ 
sign  of  a  system.  In  DoD,  this  process  extends  beyond  the 
DAS  and  involves  the  other  major  DoD  decision-support 
systems  (JCIDS,  and  PPBE)  as  well  as  decision  making  at 
the  strategy  and  policy  level.  This  cross-organizational,  Big 
"A"  systems  architecting  process  is  characterized  by  a  high 
degree  of  concurrency  where,  early  in  the  system  life  cycle, 
lower-level  system  and  technical  views  of  candidate  solutions 
begin  to  emerge  in  parallel  with  the  higher-level  strategic  and 
operational  perspectives. 

Emerging  modeling  methodologies  present  an  opportunity 
for  DoD  to  improve  collaboration  and  productivity  during  the 
concurrent  evolving  stages  of  the  Big  "A"  systems  architecting 
process,  and  this  can  contribute  to  better  acquisition  decisions 
with  concomitant  improvement  in  acquisition  outcomes.  ^ 


The  author  can  be  contacted  at  Christopher.Robinson@)dau.mM. 
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